Date: Tue,  5 Apr 94 04:30:12 PDT
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V94 #98
To: Ham-Digital


Ham-Digital Digest          Tue,  5 Apr 94       Volume 94 : Issue   98

Today's Topics:
                       Baycom modem and AMTOR?
                          CDE antenna rotor
                  Heathkit HD-15 Phonepatch Manual?
                             JNOS and SAM
                          MFJ 120C & Netrom
                          Unknown RTTY mode

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue,  5 Apr 94 12:52:58 +0400
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!EU.net!news.eunet.fi!news.spb.su!satisfy.kiae.su!kiae!relcom!demos1!dnews-server@network.ucsd.edu
Subject: Baycom modem and AMTOR?
To: ham-digital@ucsd.edu

              Does anyone have the info about the possibility to
            operate AMTOR with a simple modem in "Baycom" style.
              Here is home made modem based on TCM3105 with an
            external modulator (for 300 baud) on 2 IC's and an
            active filters on 386/7 dx 40mHz at clone.
              It's working well PR with software Baycom V1.5
            and RTTY with Hamcomm V2.1, but i am still looking
            for any other software, which allow to operate with a
            "normal" terminal program, such a SP,GP... or in any
            other mode (AMTOR, PACTOR)
              I can't find this info here on local  VHF BBS,
            because the nearest one located abt 200 km from here.
              So it is only one way to find it - this place.

               Thank's
               Andrey Petrov, UA1TFA.

             Russia
             Novgorod State University
             pap@pltx.nov.su

------------------------------

Date: Mon, 4 Apr 1994 21:20:57 GMT
From: amd!news.kpc.com!kpc!nat@decwrl.dec.com
Subject: CDE antenna rotor
To: ham-digital@ucsd.edu

Hi,
 I bought a CDE antenna rotor at a hamfest last year. The rotor is
fine but the controller seems to be flaky when I try to point the antenna
between N and West. Here are the details from the back of the controller.
 
 Model AR-33    115 V.A.C
 60 cycle       1 Amp
 Mfd by
 Cornell-Dubilier
 Electronics Div.
 Federal Pacific Electric Co.
 Fuquay-Varina, North Carolina.
 Patent No. 3.043,998

 Series 1820.

 The terminal strip has 5 wires. If anybody has a copy of the schematics
of the controller I'd like to get a copy of it. Could some knowledgeable soul
explain how the 5 wire system works. I opened the controller and the 
position dial is nice wire wound resistor of 1K ohm resistance which has
been hooked up as a variable resistor and not a potential devider. There is
a large capacitor across terminal 1 and 5. There is a transfromer with a 
center tapped secondary. The outer terminals are connected to terminals 2 and 4.
Voltage between one of the outer terminals and the center tap is 14.2 volts.
The center tap is connected to a ground trace on the circuit board.

 Is the controller setup as a bridge where the dial in the controller
is one of the arms and a similar dial up in the rotor is the other arm.
The rotor stops moving when the 2 arms get balanced. Any information will be
of great help

 Sincerely
 Nat.

-- 
-------------------------------------------------------------------------
Natarajan Gurumoorthy AB6SJ  Kubota Pacific Computer, Inc.
nat@kpc.com    2630 Walsh Avenue
Phone 408 987 3341   Santa Clara, California 95051.

------------------------------

Date: Mon, 4 Apr 1994 20:16:30 GMT
From: agate!howland.reston.ans.net!wupost!crcnis1.unl.edu!news.unomaha.edu!news.nevada.edu!jimi!envoy!jim@ames.arpa
Subject: Heathkit HD-15 Phonepatch Manual?
To: ham-digital@ucsd.edu

I recenly aquired a Heath HD-15 phone patch without a manual.  Is there 
someone who would make a copy for me?  I will gladly pay expenses.  Thank 
you very much.


-- 
-------------------------------------------------------------------------------
 Jim Mueller      | Work : (702) 689-3111 | jim@shadow.scs.unr.edu
 11865 Deodar Way | Home : (702) 677-2775 | WB7AUE@KE7KD.#NONEV.NV.USA.NOAM
 Reno, NV  89506  |                       |  

------------------------------

Date: 5 Apr 1994 03:01:12 GMT
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!news1.oakland.edu!chaos!ron@network.ucsd.edu
Subject: JNOS and SAM
To: ham-digital@ucsd.edu

John Martin (martin@server.cdpa.state.ms.US) wrote:
: One other problem though. The command prompt is not cleared (ie, it still 
: contains the command just entered) whenever the command causes you to 
: switch to another session. When I return to the console screen the previous 
: command is still on the command line following the prompt. The command IS 

Look on some archive sites for a patch for Borland C++ 2.0. This sounds just
like the problem that one of their library files had.  I used to have to put
the patch on it when I ran 2.0,  I'm running Borland C++ 3.1 now and it
works fine.

: 73 - John

73  Ron  N8FOW

------------------------------

Date: 5 Apr 94 03:00:58 GMT
From: dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org!k9cw@ucbvax.berkeley.edu
Subject: MFJ 120C & Netrom
To: ham-digital@ucsd.edu

In a previous article, chuckv@comtch.iea.com (Chuck Vyverberg) says:

>I saw some messages the last couple fo week giving detailed instructions 
>on how to get the MFJ1270C TNC to run as a netrom node.  
>

To use the MFJ1270C with netrom or TheNET, all you need to do is program
a 27256 EPROM with the modified firmware module (V2.08B is the one I have
in three digi's in central IL) and plug it in.  No circuit mods are 
required.

Installing an X1J node is another matter...

73, Drew

-- 
*-----------------------------*-------------------------------------*
|    Andrew B. White  K9CW    |    internet: k9cw@prairienet.org    |
|    ABW Associates, Ltd.     |   phone/fax: 217-643-7327           |
*-----------------------------*-------------------------------------*

------------------------------

Date: Mon, 4 Apr 1994 16:18:29 GMT
From: rit!sunsrvr6!jdc@cs.rochester.edu
Subject: Unknown RTTY mode
To: ham-digital@ucsd.edu

In article <wilsonjhCnGKA1.Ix4@netcom.com>,
John Wilson <wilsonjh@netcom.com> wrote:
>I have been monitoring some "utility" signals using an AEA PK232-MBX, 
>and have run across many strong signals that the PK232 cannot decode.
>These sound like ordinary two-tone FSK RTTY signals.
>They are often, but not always in the HF maritime bands (6, 8, 12, etc.
>Mhz), and the signal identification feature on the PD232 shows
>75 baud and mode "unknown". I hear these signals with both narrow
>and wide shifts. Anybody know what they are? A special code for an
>Oriental language? Encrypted data? Something altogether else? Anybody
>know how to copy them?
>
>Tnx es 73,
>John K3KXJ

I have also run into these signals.  I always thought the inability
to decode them was due to shortcomings in hardware interface and
software.  (I use Hamcom 2.2 with the 741 op-amp interface.)  But
this may not be the case.  

After receiving the last half of a weather-fax map, the station switched 
to RTTY.  It was strong signal, and the weather-fax came in OK.  After
it switched to RTTY I fired up Hamcom 2.2.  It was easy to figure out
frequency shift and baud rate with the "Spectrum" and "Bit length"
screens.  But the text was undeciperable gobbledygook.

Seems like it must be some type of maritime-related station.  Anybody
have more specific info?

73...Jim  N2VNO

------------------------------

Date: Mon, 4 Apr 1994 22:17:24 GMT
From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!uhog.mit.edu!news.mtholyoke.edu!world!dts@network.ucsd.edu
To: ham-digital@ucsd.edu

References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, <2nph5e$djt@hpbab.mentorg.com>.mthol
Subject : Re: NTS traffic on packet

In article <2nph5e$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes:
>In article <CnJL6K.Loq@world.std.com>, dts@world.std.com (Daniel T Senie) writes:
>|> In article <2nejic$j75@hp-col.col.hp.com> jms@col.hp.com (Mike Stansberry) writes:
>|> >Jeffrey D. Angus (jangus@skyld.grendel.com) wrote:
>
>|> I have lately seen traffic duplicated 2 or 3 times. One message I sent to
>|> my STM at the other end of the section got there 4 times. We have had
>|> a rash of multiple NTS deliveries.
>
>This is a very serious problem.
>
>There are many possible causes, but they all come down to poor operating
>practices by the sysops.  If the sysops had things set up reasonably,
>and made certain their systems were operating properly, then there would
>be no (zero, zilch, none) duplicated bulletins.
>
>Personal messages and NTS traffic are handled differently.
>Duplicates are allowed to occur, rather than lose an occasional message.
>However, these duplicates should be rare: 1 in 1000 perhaps.

This raises some alarm bells with me. Networks need to either send or not
send messages. Protocols are designed to be able to be sure of such things.
Could you imagine if something like an international money transfer were
occasionally duplicated on the commercial networks? It sounds like the
protocols involved (in nthis case, the handling methods) may need some
review.

Why is the software designed to allow even an occasional duplicate? Why
is there otherwise the possibility of a lost message?

>
>Sounds like the sysops involved have not done a very good job of
>getting their systems to work.
>
>You can't just "Load the BBS software and away you go."
>It takes thought, planning, cooperation, and coordination to make a network
>work properly.  In the past couple years, I have noticed a distinct lack of
>all of the above in many parts of the BBS network.
>
>Perhaps time for some organization to take a leadership postion here?
>
>(ARRL, where are you when you are needed?)

Well, I am the local ARRL person (Section Manager). I'm gathering information
so that I can intelligently address the appropriate people about the
problem.

In this area the North East Digital Association runs the AX.25 net, so it 
would seem to make sense that they are the ones to take the leadership
position on this. Perhaps I need to appoint an Assistant Section Manager
who can oversee packet operations, or something like that...

>
>   ...  Hank
>
>-- 
>
>Hank Oredson @ Mentor Graphics
>Internet     : hank_oredson@mentorg.com
>Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM

Thanks for your response, by the way. I do appreciate that you and others
put in quite a bit of time on the BBS software. Overall things seem to work
pretty well, but it gives a false sense of security sometimes, when things
like the multitude of dupes we've seen happen.

thanks and 73,

Dan N1JEB SM WMA
-- 
---------------------------------------------------------------
Daniel Senie                 Internet:     dts@world.std.com
Daniel Senie Consulting                    n1jeb@world.std.com
508-779-0439                 Compuserve:   74176,1347

------------------------------

Date: Mon, 4 Apr 1994 22:24:16 GMT
From: spsgate!mogate!newsgate!dtsdev0!kinzer@uunet.uu.net
To: ham-digital@ucsd.edu

References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, <2nph5e$djt@hpbab.mentorg.com>ev0
Subject : Re: NTS traffic on packet


  All I can say is I'm glad no one is charged with maintaining the 
ionosphere.  Just imagine the bitching out they'd get.

  I do have one positive contribution to make.  If duplicate messages are
really a big problem, then each (or each destination) node could keep a
hash code of the content of every message that has been seen in the past 
N days.  If any hash code matches, delete the message without passing
it along or making it available for download.  Ignoring headers allows 
messages that have taken different routes to still be zapped.  Using a 
good hash and enough bits and enough days history you could select the 
probability of erroneously dropping a non-duplicate to less than the 
probability of an NTS operator accepting a message yet dying before he 
delivers it.

  Say 12 bits for date received (would allow over 10 years of data to
accumulate and still allow for deleting by day, talk about overkill) and
52 bits of hash for a total of 8 bytes retained per message.  If 100
messages arrived daily, and we kept 120 days worth, we would be keeping
96K bytes of data, not even a floppy disk worth.  There would be 12,000
hash patterns (no duplicates) from a data space of 2^52, giving the
possibility of erroneously deleting a random incoming message of
0.000000000266 percent.  Add a few more bits to the hash code if that's
not good enough for you.  Even as it is, at 100 messages daily, it means 
only one dropped message every 10 million years on average.  I don't think 
this will be the weak link in delivering messages.

  Of course, I don't claim to be a mathematician or statistician, so the
above numbers should be taken as a general approximation at best.  Still,
it's one avenue open for exploration.

-dave

------------------------------

Date: 5 Apr 1994 02:20:07 GMT
From: nothing.ucsd.edu!brian@network.ucsd.edu
To: ham-digital@ucsd.edu

References <2n7bup$3v3@hpbab.mentorg.com>, <1994Mar29.100554.3059@hemlock.cray.com>, <2nphhd$djt@hpbab.mentorg.com>
Subject : Re: [REPOST] The # in PBBS addresses....

In article <2nphhd$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes:
>You are perhaps talking about the internet, which chose to ignore
>the existing use of NA in one of it's connected networks?

Oh jeez, Hank, stop making things up.  The AMPR.ORG domain has never used
the ham bbs hierarchical routing/addressing scheme to name hosts.

With some exceptions, the namespace of the AMPR.ORG domain consists
solely of callsigns within the domain.  Names are not routes, routes
are not names, and mixing them up is one of the worst possible mistakes
a network architect could make.

That means that whilst you might see
 W0RLI.AMPR.ORG
or
 BBS.W0RLI.AMPR.ORG
you won't see
 W0RLI.#NNJ.NJ.USA.NOAM.AMPR.ORG
or the like

Ever.
  - Brian

------------------------------

End of Ham-Digital Digest V94 #98
******************************
******************************
